Like each month, have a look at the work funded by Freexian s Debian LTS offering. Some notable fixes which were made in LTS during the month of November include the gnutls28 cryptographic library and the freerdp2 Remote Desktop Protocol client/server implementation. The gnutls28 update was prepared by LTS contributor Markus Koschany and dealt with a timing attack which could be used to compromise a cryptographic system, while the freerdp2 update was prepared by LTS contributor Tobias Frost and is the result of work spanning 3 months to deal with dozens of vulnerabilities. In addition to the many ordinary LTS tasks which were completed (CVE triage, patch backports, package updates, etc), there were several contributions by LTS contributors for the benefit of Debian stable and old-stable releases, as well as for the benefit of upstream projects. LTS contributor Abhijith PA uploaded an update of the puma package to unstable in order to fix a vulnerability in that package while LTS contributor Thosten Alteholz sponsored an upload to unstable of libde265 and himself made corresponding uploads of libde265 to Debian stable and old-stable. LTS contributor Bastien Roucari s developed patches for vulnerabilities in zbar and audiofile which were then provided to the respective upstream projects. Updates to packages in Debian stable were made by Markus Koschany to deal with security vulnerabilities and by Chris Lamb to deal with some non-security bugs. As always, the LTS strives to provide high quality updates to packages under the direct purview of the LTS team while also rendering assistance to maintainers, the stable security team, and upstream developers whenever practical.

Debian LTS contributors In November, 18 contributors have been paid to work on Debian LTS, their reports are available:

Abhijith PA did 7.0h (out of 0h assigned and 14.0h from previous period), thus carrying over 7.0h to the next month.

Adrian Bunk did 15.0h (out of 14.0h assigned and 9.75h from previous period), thus carrying over 8.75h to the next month.

Anton Gladky did 10.0h (out of 9.5h assigned and 5.5h from previous period), thus carrying over 5.0h to the next month.

Bastien Roucari s did 16.0h (out of 18.25h assigned and 1.75h from previous period), thus carrying over 4.0h to the next month.

Ben Hutchings did 12.0h (out of 16.5h assigned and 12.25h from previous period), thus carrying over 16.75h to the next month.

Chris Lamb did 18.0h (out of 17.25h assigned and 0.75h from previous period).

Emilio Pozuelo Monfort did 15.5h (out of 23.5h assigned and 0.25h from previous period), thus carrying over 8.25h to the next month.

Guilhem Moulin did 13.0h (out of 12.0h assigned and 8.0h from previous period), thus carrying over 7.0h to the next month.

Lee Garrett did 14.5h (out of 16.75h assigned and 7.0h from previous period), thus carrying over 9.25h to the next month.

Markus Koschany did 30.0h (out of 30.0h assigned).

Ola Lundqvist did 6.5h (out of 8.25h assigned and 15.5h from previous period), thus carrying over 17.25h to the next month.

Roberto C. S nchez did 5.5h (out of 12.0h assigned), thus carrying over 6.5h to the next month.

Santiago Ruano Rinc n did 3.25h (out of 13.62h assigned and 2.375h from previous period), thus carrying over 12.745h to the next month.

Sean Whitton did 3.25h (out of 10.0h assigned), thus carrying over 6.75h to the next month.

Sylvain Beucler did 10.0h (out of 13.5h assigned and 10.25h from previous period), thus carrying over 13.75h to the next month.

Thorsten Alteholz did 14.0h (out of 14.0h assigned).

Tobias Frost did 12.0h (out of 12.0h assigned).

Utkarsh Gupta did 0.0h (out of 6.0h assigned and 17.75h from previous period), thus carrying over 23.75h to the next month.

Evolution of the situation In November, we have released 35 DLAs.

Thanks to our sponsors Sponsors that joined recently are in bold.

Platinum sponsors:

TOSHIBA (for 99 months)

Civil Infrastructure Platform (CIP) (for 67 months)

Gold sponsors:

Roche Diagnostics International AG (for 110 months)

Linode (for 104 months)

Babiel GmbH (for 93 months)

Plat Home (for 93 months)

University of Oxford (for 49 months)

Deveryware (for 36 months)

VyOS Inc (for 31 months)

EDF SA (for 20 months)

Silver sponsors:

Domeneshop AS (for 114 months)

Nantes M tropole (for 108 months)

Univention GmbH (for 100 months)

Universit Jean Monnet de St Etienne (for 100 months)

Ribbon Communications, Inc. (for 94 months)

Exonet B.V. (for 84 months)

Leibniz Rechenzentrum (for 78 months)

CINECA (for 67 months)

Minist re de l Europe et des Affaires trang res (for 61 months)

Cloudways Ltd (for 51 months)

Dinahosting SL (for 49 months)

Bauer Xcel Media Deutschland KG (for 43 months)

Platform.sh SAS (for 43 months)

Moxa Inc. (for 37 months)

sipgate GmbH (for 34 months)

OVH US LLC (for 32 months)

Tilburg University (for 32 months)

GSI Helmholtzzentrum f r Schwerionenforschung GmbH (for 23 months)

Soliton Systems K.K. (for 21 months)

Bronze sponsors:

Evolix (for 115 months)

Seznam.cz, a.s. (for 115 months)

Intevation GmbH (for 112 months)

Linuxhotel GmbH (for 112 months)

Daevel SARL (for 110 months)

Bitfolk LTD (for 109 months)

Megaspace Internet Services GmbH (for 109 months)

Greenbone AG (for 108 months)

NUMLOG (for 108 months)

WinGo AG (for 108 months)

Ecole Centrale de Nantes - LHEEA (for 104 months)

Entr ouvert (for 99 months)

Adfinis AG (for 96 months)

GNI MEDIA (for 91 months)

Laboratoire LEGI - UMR 5519 / CNRS (for 91 months)

Tesorion (for 91 months)

Bearstech (for 82 months)

LiHAS (for 82 months)

Catalyst IT Ltd (for 77 months)

Supagro (for 72 months)

Demarcq SAS (for 71 months)

Universit Grenoble Alpes (for 57 months)

TouchWeb SAS (for 49 months)

SPiN AG (for 46 months)

CoreFiling (for 41 months)

Institut des sciences cognitives Marc Jeannerod (for 36 months)

Observatoire des Sciences de l Univers de Grenoble (for 33 months)

Tem Innovations GmbH (for 27 months)

WordFinder.pro (for 27 months)

CNRS DT INSU R sif (for 26 months)

Alter Way (for 19 months)

Institut Camille Jordan (for 8 months)

dkg's New OpenPGP certificate in December 2023 In December of 2023, I'm moving to a new OpenPGP certificate. You might know my old OpenPGP certificate, which had an fingerprint of C29F8A0C01F35E34D816AA5CE092EB3A5CA10DBA. My new OpenPGP certificate has a fingerprint of: D477040C70C2156A5C298549BB7E9101495E6BF7. Both certificates have the same set of User IDs:

Daniel Kahn Gillmor
<dkg@debian.org>
<dkg@fifthhorseman.net>

You can find a version of this transition statement signed by both the old and new certificates at: https://dkg.fifthhorseman.net/2023-dkg-openpgp-transition.txt The new OpenPGP certificate is:

When I have some reasonable number of certifications, i'll update the certificate associated with my e-mail addresses on https://keys.openpgp.org, in DANE, and in WKD. Until then, those lookups should continue to provide the old certificate.

A new release of my mixed collection of things package dang package arrived at CRAN a little while ago. The dang package regroups a few functions of mine that had no other home as for example lsos() from a StackOverflow question from 2009 (!!), the overbought/oversold price band plotter from an older blog post, the market monitor blogged about as well as the checkCRANStatus() function tweeted about by Tim Taylor. And more so take a look. This release brings a number of updates, including a rather nice improvement to the market monitor making updates buttery smooth and not flickering (with big thanks to Paul Murrell who calmly pointed out once again that base R does of course have the functionality I was seeking) as well as three new functions (!!) and then a little maintenance on the -Wformat print format string issue that kept everybody busy this week. The NEWS entry follows.

Changes in version 0.0.16 (2023-12-02)

Added new function str.language() based on post by Bill Dunlap

Added new argument sleep in intradayMarketMonitor

Switched to dev.hold() and dev.flush() in intradayMarketMonitor with thanks to Paul Murrell

Updated continued integration setup, twice, and package badges

Added new function shadowedPackages

Added new function limitDataTableCores

Updated two error() calls to updated tidyCpp signature to not tickle -Wformat warnings under R-devel

Updated two URL to please link checks in R-devel

Switch two tests for variable of variable to is.* and inherits(), respectively

Courtesy of my CRANberries, there is a comparison to [the previous release][previous releases]. For questions or comments use the the issue tracker at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Did a tea ceremony yesterday. Having fun talking about stuff is the most important part.

A new maintenance release 0.1.11 of the RcppSimdJson package is now on CRAN. RcppSimdJson wraps the fantastic and genuinely impressive simdjson library by Daniel Lemire and collaborators. Via very clever algorithmic engineering to obtain largely branch-free code, coupled with modern C++ and newer compiler instructions, it results in parsing gigabytes of JSON parsed per second which is quite mindboggling. The best-case performance is faster than CPU speed as use of parallel SIMD instructions and careful branch avoidance can lead to less than one cpu cycle per byte parsed; see the video of the talk by Daniel Lemire at QCon. This release responds to a CRAN request to address issues now identified by -Wformat -Wformat-security. These are frequently pretty simple changes as it was here: all it took was an call to compileAttributes() from an updated Rcpp version which now injects "%s" as a format string when calling Rf_error(). The (very short) NEWS entry for this release follows.

Changes in version 0.1.11 (2023-11-28)

RcppExports.cpp has been regenerated under an update Rcpp to address a print format warning (Dirk in #88).

Courtesy of my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo. If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

That's all folks ...
Sadly, nothing too much to report.I delivered a very quick three slides lightning talk on Accessibility, WCAG [Web Content Accessibility Guidelines] version 2.2 and a request for Debian to do better

WCAG 2.2: WCAG 2.2 AbstractDebian-accessibility mailing list link: debian-accessibilityI watched the other lightning talks but then left at 1500 - missing three good talks - to drive home at least partly in daylight.

A great four days - the chance to put some names to faces and to recharge in Debian spaces.

Thanks to all involved and especially ...
Thanks to Cambridge Debian folk for helping arrange evening meals, lifts and so on and especially to those who also happen be ARM employees who were badging us in and out through the four days

Thanks to those who staffed Front Desk on both days and, especially, also to the ARM security guards who let us into site at 0745 on all four days and to Mark who did the weekend shift inside the building for Saturday and Sunday.

Thanks to ARM for excellent facilities, food, coffee, hosting us and coffee, to Codethink for sponsoring - and a lecture from Sudip and some interesting hardware - and Pexip for Pexip sponsorship (and employee attendance).

Here's to the next opportunity, whenever that may be.

Like each month, have a look at the work funded by Freexian s Debian LTS offering.

Debian LTS contributors In October, 18 contributors have been paid to work on Debian LTS, their reports are available:

Adrian Bunk did 8.0h (out of 7.75h assigned and 10.0h from previous period), thus carrying over 9.75h to the next month.

Anton Gladky did 9.5h (out of 9.5h assigned and 5.5h from previous period), thus carrying over 5.5h to the next month.

Bastien Roucari s did 16.0h (out of 16.75h assigned and 1.0h from previous period), thus carrying over 1.75h to the next month.

Ben Hutchings did 8.0h (out of 17.75h assigned), thus carrying over 9.75h to the next month.

Chris Lamb did 17.0h (out of 17.75h assigned), thus carrying over 0.75h to the next month.

Emilio Pozuelo Monfort did 17.5h (out of 17.75h assigned), thus carrying over 0.25h to the next month.

Guilhem Moulin did 9.75h (out of 17.75h assigned), thus carrying over 8.0h to the next month.

Helmut Grohne did 1.5h (out of 10.0h assigned), thus carrying over 8.5h to the next month.

Lee Garrett did 10.75h (out of 17.75h assigned), thus carrying over 7.0h to the next month.

Markus Koschany did 30.0h (out of 30.0h assigned).

Ola Lundqvist did 4.0h (out of 0h assigned and 19.5h from previous period), thus carrying over 15.5h to the next month.

Roberto C. S nchez did 12.0h (out of 5.0h assigned and 7.0h from previous period).

Santiago Ruano Rinc n did 13.625h (out of 7.75h assigned and 8.25h from previous period), thus carrying over 2.375h to the next month.

Sean Whitton did 13.0h (out of 6.0h assigned and 7.0h from previous period).

Sylvain Beucler did 7.5h (out of 11.25h assigned and 6.5h from previous period), thus carrying over 10.25h to the next month.

Thorsten Alteholz did 14.0h (out of 14.0h assigned).

Tobias Frost did 16.0h (out of 9.25h assigned and 6.75h from previous period).

Utkarsh Gupta did 0.0h (out of 0.75h assigned and 17.0h from previous period), thus carrying over 17.75h to the next month.

Evolution of the situation In October, we have released 49 DLAs. Of particular note in the month of October, LTS contributor Chris Lamb issued DLA 3627-1 pertaining to Redis, the popular key-value database similar to Memcached, which was vulnerable to an authentication bypass vulnerability. Fixing this vulnerability involved dealing with a race condition that could allow another process an opportunity to establish an otherwise unauthorized connection. LTS contributor Markus Koschany was involved in the mitigation of CVE-2023-44487, which is a protocol-level vulnerability in the HTTP/2 protocol. The impacts within Debian involved multiple packages, across multiple releases, with multiple advisories being released (both DSA for stable and old-stable, and DLA for LTS). Markus reviewed patches and security updates prepared by other Debian developers, investigated reported regressions, provided patches for the aforementioned regressions, and issued several security updates as part of this. Additionally, as MariaDB 10.3 (the version originally included with Debian buster) passed end-of-life earlier this year, LTS contributor Emilio Pozuelo Monfort has begun investigating the feasibility of backporting MariaDB 10.11. The work is in early stages, with much testing and analysis remaining before a final decision can be made, as this only one of several available potential courses of action concerning MariaDB. Finally, LTS contributor Lee Garrett has invested considerable effort into the development the Functional Test Framework here. While so far only an initial version has been published, it already has several features which we intend to begin leveraging for testing of LTS packages. In particular, the FTF supports provisioning multiple VMs for the purposes of performing functional tests of network-facing services (e.g., file services, authentication, etc.). These tests are in addition to the various unit-level tests which are executed during package build time. Development work will continue on FTF and as it matures and begins to see wider use within LTS we expect to improve the quality of the updates we publish.

Thanks to our sponsors Sponsors that joined recently are in bold.

Platinum sponsors:

TOSHIBA (for 98 months)

Civil Infrastructure Platform (CIP) (for 66 months)

Gold sponsors:

Roche Diagnostics International AG (for 109 months)

Linode (for 103 months)

Babiel GmbH (for 92 months)

Plat Home (for 92 months)

University of Oxford (for 48 months)

Deveryware (for 35 months)

VyOS Inc (for 30 months)

EDF SA (for 19 months)

Silver sponsors:

Domeneshop AS (for 113 months)

Nantes M tropole (for 107 months)

Univention GmbH (for 99 months)

Universit Jean Monnet de St Etienne (for 99 months)

Ribbon Communications, Inc. (for 93 months)

Exonet B.V. (for 83 months)

Leibniz Rechenzentrum (for 77 months)

CINECA (for 66 months)

Minist re de l Europe et des Affaires trang res (for 60 months)

Cloudways Ltd (for 50 months)

Dinahosting SL (for 48 months)

Bauer Xcel Media Deutschland KG (for 42 months)

Platform.sh (for 42 months)

Moxa Inc. (for 36 months)

sipgate GmbH (for 33 months)

OVH US LLC (for 31 months)

Tilburg University (for 31 months)

GSI Helmholtzzentrum f r Schwerionenforschung GmbH (for 23 months)

Soliton Systems K.K. (for 20 months)

Bronze sponsors:

Evolix (for 114 months)

Seznam.cz, a.s. (for 114 months)

Intevation GmbH (for 111 months)

Linuxhotel GmbH (for 111 months)

Daevel SARL (for 109 months)

Bitfolk LTD (for 108 months)

Megaspace Internet Services GmbH (for 108 months)

Greenbone AG (for 107 months)

NUMLOG (for 107 months)

WinGo AG (for 107 months)

Ecole Centrale de Nantes - LHEEA (for 103 months)

Entr ouvert (for 98 months)

Adfinis AG (for 95 months)

GNI MEDIA (for 90 months)

Laboratoire LEGI - UMR 5519 / CNRS (for 90 months)

Tesorion (for 90 months)

Bearstech (for 81 months)

LiHAS (for 81 months)

Catalyst IT Ltd (for 76 months)

Supagro (for 71 months)

Demarcq SAS (for 70 months)

Universit Grenoble Alpes (for 56 months)

TouchWeb SAS (for 48 months)

SPiN AG (for 45 months)

CoreFiling (for 40 months)

Institut des sciences cognitives Marc Jeannerod (for 35 months)

Observatoire des Sciences de l Univers de Grenoble (for 32 months)

Tem Innovations GmbH (for 27 months)

WordFinder.pro (for 26 months)

CNRS DT INSU R sif (for 25 months)

Alter Way (for 18 months)

Institut Camille Jordan (for 7 months)

Today, 12 years after the meeting where AppStream was first discussed and 11 years after I released a prototype implementation I am excited to announce AppStream 1.0!

Check it out on GitHub, or get the release tarball or read the documentation or release notes!

Some nostalgic memories I was not in the original AppStream meeting, since in 2011 I was extremely busy with finals preparations and ball organization in high school, but I still vividly remember sitting at school in the students lounge during a break and trying to catch the really choppy live stream from the meeting on my borrowed laptop (a futile exercise, I watched parts of the blurry recording later). I was extremely passionate about getting software deployment to work better on Linux and to improve the overall user experience, and spent many hours on the PackageKit IRC channel discussing things with many amazing people like Richard Hughes, Daniel Nicoletti, Sebastian Heinlein and others. At the time I was writing a software deployment tool called Listaller this was before Linux containers were a thing, and building it was very tough due to technical and personal limitations (I had just learned C!). Then in university, when I intended to recreate this tool, but for real and better this time as a new project called Limba, I needed a way to provide metadata for it, and AppStream fit right in! Meanwhile, Richard Hughes was tackling the UI side of things while creating GNOME Software and needed a solution as well. So I implemented a prototype and together we pretty much reshaped the early specification from the original meeting into what would become modern AppStream. Back then I saw AppStream as a necessary side-project for my actual project, and didn t even consider me as the maintainer of it for quite a while (I hadn t been at the meeting afterall). All those years ago I had no idea that ultimately I was developing AppStream not for Limba, but for a new thing that would show up later, with an even more modern design called Flatpak. I also had no idea how incredibly complex AppStream would become and how many features it would have and how much more maintenance work it would be and also not how ubiquitous it would become. The modern Linux desktop uses AppStream everywhere now, it is supported by all major distributions, used by Flatpak for metadata, used for firmware metadata via Richard s fwupd/LVFS, runs on every Steam Deck, can be found in cars and possibly many places I do not know yet.

What is new in 1.0?

API breaks The most important thing that s new with the 1.0 release is a bunch of incompatible changes. For the shared libraries, all deprecated API elements have been removed and a bunch of other changes have been made to improve the overall API and especially make it more binding-friendly. That doesn t mean that the API is completely new and nothing looks like before though, when possible the previous API design was kept and some changes that would have been too disruptive have not been made. Regardless of that, you will have to port your AppStream-using applications. For some larger ones I already submitted patches to build with both AppStream versions, the 0.16.x stable series as well as 1.0+. For the XML specification, some older compatibility for XML that had no or very few users has been removed as well. This affects for example `release` elements that reference downloadable data without an `artifact` block, which has not been supported for a while. For all of these, I checked to remove only things that had close to no users and that were a significant maintenance burden. So as a rule of thumb: If your XML validated with no warnings with the 0.16.x branch of AppStream, it will still be 100% valid with the 1.0 release. Another notable change is that the generated output of AppStream 1.0 will always be 1.0 compliant, you can not make it generate data for versions below that (this greatly reduced the maintenance cost of the project).

Developer element For a long time, you could set the developer name using the top-level `developer_name` tag. With AppStream 1.0, this is changed a bit. There is now a `developer` tag with a `name` child (that can be translated unless the `translate="no"` attribute is set on it). This allows future extensibility, and also allows to set a machine-readable `id` attribute in the `developer` element. This permits software centers to group software by developer easier, without having to use heuristics. If we decide to extend the developer information per-app in future, this is also now possible. Do not worry though the `developer_name` tag is also still read, so there is no high pressure to update. The old 0.16.x stable series also has this feature backported, so it can be available everywhere. Check out the developer tag specification for more details.

Scale factor for screenshots Screenshot images can now have a `scale` attribute, to indicate an (integer) scaling factor to apply. This feature was a breaking change and therefore we could not have it for the longest time, but it is now available. Please wait a bit for AppStream 1.0 to become deployed more widespread though, as using it with older AppStream versions may lead to issues in some cases. Check out the screenshots tag specification for more details.

Screenshot environments It is now possible to indicate the environment a screenshot was recorded in (GNOME, GNOME Dark, KDE Plasma, Windows, etc.) via an `environment` attribute on the respective `screenshot` tag. This was also a breaking change, so use it carefully for now! If projects want to, they can use this feature to supply dedicated screenshots depending on the environment the application page is displayed in. Check out the screenshots tag specification for more details.

References tag This is a feature more important for the scientific community and scientific applications. Using the `references` tag, you can associate the AppStream component with a DOI (Digital object identifier) or provide a link to a CFF file to provide citation information. It also allows to link to other scientific registries. Check out the references tag specification for more details.

Release tags Releases can have tags now, just like components. This is generally not a feature that I expect to be used much, but in certain instances it can become useful with a cooperating software center, for example to tag certain releases as long-term supported versions.

Multi-platform support Thanks to the interest and work of many volunteers, AppStream (mostly) runs on FreeBSD now, a NetBSD port exists, support for macOS was written and a Windows port is on its way! Thank you to everyone working on this

Better compatibility checks For a long time I thought that the AppStream library should just be a thin layer above the XML and that software centers should just implement a lot of the actual logic. This has not been the case for a while, but there was still a lot of complex AppStream features that were hard for software centers to implement and where it makes sense to have one implementation that projects can just use. The validation of component relations is one such thing. This was implemented in 0.16.x as well, but 1.0 vastly improves upon the compatibility checks, so you can now just run as_component_check_relations and retrieve a detailed list of whether the current component will run well on the system. Besides better API for software developers, the `appstreamcli` utility also has much improved support for relation checks, and I wrote about these changes in a previous post. Check it out! With these changes, I hope this feature will be used much more, and beyond just drivers and firmware.

So much more! The changelog for the 1.0 release is huge, and there are many papercuts resolved and changes made that I did not talk about here, like us using gi-docgen (instead of gtkdoc) now for nice API documentation, or the many improvements that went into better binding support, or better search, or just plain bugfixes.

Outlook I expect the transition to 1.0 to take a bit of time. AppStream has not broken its API for many, many years (since 2016), so a bunch of places need to be touched even if the changes themselves are minor in many cases. In hindsight, I should have also released 1.0 much sooner and it should not have become such a mega-release, but that was mainly due to time constraints. So, what s in it for the future? Contrary to what I thought, AppStream does not really seem to be done and fetature complete at a point, there is always something to improve, and people come up with new usecases all the time. So, expect more of the same in future: Bugfixes, validator improvements, documentation improvements, better tools and the occasional new feature. Onwards to 1.0.1!

The chrpath package provide a simple command line tool to remove or modify the rpath or runpath of compiled ELF program. It is almost 10 years since I updated the code base, but I stumbled over the tool today, and decided it was time to move the code base from Subversion to git and find a new home for it, as the previous one (Debian Alioth) has been shut down. I decided to go with Codeberg this time, as it is my git service of choice these days, did a quick and dirty migration to git and updated the code with a few patches I found in the Debian bug tracker. These are the release notes: New in 0.17 released 2023-11-10:

Moved project to Codeberg, as Alioth is shut down.
Add Solaris support (use <sys/byteorder.h> instead of <byteswap.h>). Patch from Rainer Orth.
Added missing newline from printf() line. Patch from Frank Dana.
Corrected handling of multiple ELF sections. Patch from Frank Dana.
Updated build rules for .deb. Partly based on patch from djcj.

The latest edition is tagged and available from https://codeberg.org/pere/chrpath. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

TL;DR: This blog post explores the color capabilities of AMD hardware and how they are exposed to userspace through driver-specific properties. It discusses the different color blocks in the AMD Display Core Next (DCN) pipeline and their capabilities, such as predefined transfer functions, 1D and 3D lookup tables (LUTs), and color transformation matrices (CTMs). It also highlights the differences in AMD HW blocks for pre and post-blending adjustments, and how these differences are reflected in the available driver-specific properties. Overall, this blog post provides a comprehensive overview of the color capabilities of AMD hardware and how they can be controlled by userspace applications through driver-specific properties. This information is valuable for anyone who wants to develop applications that can take advantage of the AMD color management pipeline. Get a closer look at each hardware block s capabilities, unlock a wealth of knowledge about AMD display hardware, and enhance your understanding of graphics and visual computing. Stay tuned for future developments as we embark on a quest for GPU color capabilities in the ever-evolving realm of rainbow treasures.
Operating Systems can use the power of GPUs to ensure consistent color reproduction across graphics devices. We can use GPU-accelerated color management to manage the diversity of color profiles, do color transformations to convert between High-Dynamic-Range (HDR) and Standard-Dynamic-Range (SDR) content and color enhacements for wide color gamut (WCG). However, to make use of GPU display capabilities, we need an interface between userspace and the kernel display drivers that is currently absent in the Linux/DRM KMS API. In the previous blog post I presented how we are expanding the Linux/DRM color management API to expose specific properties of AMD hardware. Now, I ll guide you to the color features for the Linux/AMD display driver. We embark on a journey through DRM/KMS, AMD Display Manager, and AMD Display Core and delve into the color blocks to uncover the secrets of color manipulation within AMD hardware. Here we ll talk less about the color tools and more about where to find them in the hardware. We resort to driver-specific properties to reach AMD hardware blocks with color capabilities. These blocks display features like predefined transfer functions, color transformation matrices, and 1-dimensional (1D LUT) and 3-dimensional lookup tables (3D LUT). Here, we will understand how these color features are strategically placed into color blocks both before and after blending in Display Pipe and Plane (DPP) and Multiple Pipe/Plane Combined (MPC) blocks. That said, welcome back to the second part of our thrilling journey through AMD s color management realm!

AMD Display Driver in the Linux/DRM Subsystem: The Journey In my 2022 XDC talk I m not an AMD expert, but , I briefly explained the organizational structure of the Linux/AMD display driver where the driver code is bifurcated into a Linux-specific section and a shared-code portion. To reveal AMD s color secrets through the Linux kernel DRM API, our journey led us through these layers of the Linux/AMD display driver s software stack. It includes traversing the DRM/KMS framework, the AMD Display Manager (DM), and the AMD Display Core (DC) [1]. The DRM/KMS framework provides the atomic API for color management through KMS properties represented by `struct drm_property`. We extended the color management interface exposed to userspace by leveraging existing resources and connecting them with driver-specific functions for managing modeset properties. On the AMD DC layer, the interface with hardware color blocks is established. The AMD DC layer contains OS-agnostic components that are shared across different platforms, making it an invaluable resource. This layer already implements hardware programming and resource management, simplifying the external developer s task. While examining the DC code, we gain insights into the color pipeline and capabilities, even without direct access to specifications. Additionally, AMD developers provide essential support by answering queries and reviewing our work upstream. The primary challenge involved identifying and understanding relevant AMD DC code to configure each color block in the color pipeline. However, the ultimate goal was to bridge the DC color capabilities with the DRM API. For this, we changed the AMD DM, the OS-dependent layer connecting the DC interface to the DRM/KMS framework. We defined and managed driver-specific color properties, facilitated the transport of user space data to the DC, and translated DRM features and settings to the DC interface. Considerations were also made for differences in the color pipeline based on hardware capabilities.

Exploring Color Capabilities of the AMD display hardware Now, let s dive into the exciting realm of AMD color capabilities, where a abundance of techniques and tools await to make your colors look extraordinary across diverse devices. First, we need to know a little about the color transformation and calibration tools and techniques that you can find in different blocks of the AMD hardware. I borrowed some images from [2] [3] [4] to help you understand the information.

Predefined Transfer Functions (Named Fixed Curves): Transfer functions serve as the bridge between the digital and visual worlds, defining the mathematical relationship between digital color values and linear scene/display values and ensuring consistent color reproduction across different devices and media. You can learn more about curves in the chapter GPU Gems 3 - The Importance of Being Linear by Larry Gritz and Eugene d Eon. ITU-R 2100 introduces three main types of transfer functions:

OETF: the opto-electronic transfer function, which converts linear scene light into the video signal, typically within a camera.

EOTF: electro-optical transfer function, which converts the video signal into the linear light output of the display.

OOTF: opto-optical transfer function, which has the role of applying the rendering intent .

AMD s display driver supports the following pre-defined transfer functions (aka named fixed curves):

Linear/Unity: linear/identity relationship between pixel value and luminance value;

Gamma 2.2, Gamma 2.4, Gamma 2.6: pure power functions;

sRGB: 2.4: The piece-wise transfer function from IEC 61966-2-1:1999;

BT.709: has a linear segment in the bottom part and then a power function with a 0.45 (~1/2.22) gamma for the rest of the range; standardized by ITU-R BT.709-6;

PQ (Perceptual Quantizer): used for HDR display, allows luminance range capability of 0 to 10,000 nits; standardized by SMPTE ST 2084.

These capabilities vary depending on the hardware block, with some utilizing hardcoded curves and others relying on AMD s color module to construct curves from standardized coefficients. It also supports user/custom curves built from a lookup table.

1D LUTs (1-dimensional Lookup Table): A 1D LUT is a versatile tool, defining a one-dimensional color transformation based on a single parameter. It s very well explained by Jeremy Selan at GPU Gems 2 - Chapter 24 Using Lookup Tables to Accelerate Color Transformations It enables adjustments to color, brightness, and contrast, making it ideal for fine-tuning. In the Linux AMD display driver, the atomic API offers a 1D LUT with 4096 entries and 8-bit depth, while legacy gamma uses a size of 256.

3D LUTs (3-dimensional Lookup Table): These tables work in three dimensions red, green, and blue. They re perfect for complex color transformations and adjustments between color channels. It s also more complex to manage and require more computational resources. Jeremy also explains 3D LUT at GPU Gems 2 - Chapter 24 Using Lookup Tables to Accelerate Color Transformations

CTM (Color Transformation Matrices): Color transformation matrices facilitate the transition between different color spaces, playing a crucial role in color space conversion.

HDR Multiplier: HDR multiplier is a factor applied to the color values of an image to increase their overall brightness.

AMD Color Capabilities in the Hardware Pipeline First, let s take a closer look at the AMD Display Core Next hardware pipeline in the Linux kernel documentation for AMDGPU driver - Display Core Next In the AMD Display Core Next hardware pipeline, we encounter two hardware blocks with color capabilities: the Display Pipe and Plane (DPP) and the Multiple Pipe/Plane Combined (MPC). The DPP handles color adjustments per plane before blending, while the MPC engages in post-blending color adjustments. In short, we expect DPP color capabilities to match up with DRM plane properties, and MPC color capabilities to play nice with DRM CRTC properties. Note: here s the catch there are some DRM CRTC color transformations that don t have a corresponding AMD MPC color block, and vice versa. It s like a puzzle, and we re here to solve it!

AMD Color Blocks and Capabilities We can finally talk about the color capabilities of each AMD color block. As it varies based on the generation of hardware, let s take the DCN3+ family as reference. What s possible to do before and after blending depends on hardware capabilities describe in the kernel driver by

struct
dpp_color_caps

and

struct
mpc_color_caps

. The AMD Steam Deck hardware provides a tangible example of these capabilities. Therefore, we take SteamDeck/DCN301 driver as an example and look at the Color pipeline capabilities described in the file: driver/gpu/drm/amd/display/dcn301/dcn301_resources.c

/* Color pipeline capabilities */
dc->caps.color.dpp.dcn_arch = 1; // If it is a Display Core Next (DCN): yes. Zero means DCE.
dc->caps.color.dpp.input_lut_shared = 0;
dc->caps.color.dpp.icsc = 1; // Intput Color Space Conversion  (CSC) matrix.
dc->caps.color.dpp.dgam_ram = 0; // The old degamma block for degamma curve (hardcoded and LUT).  Gamma correction  is the new one.
dc->caps.color.dpp.dgam_rom_caps.srgb = 1; // sRGB hardcoded curve support
dc->caps.color.dpp.dgam_rom_caps.bt2020 = 1; // BT2020 hardcoded curve support (seems not actually in use)
dc->caps.color.dpp.dgam_rom_caps.gamma2_2 = 1; // Gamma 2.2 hardcoded curve support
dc->caps.color.dpp.dgam_rom_caps.pq = 1; // PQ hardcoded curve support
dc->caps.color.dpp.dgam_rom_caps.hlg = 1; // HLG hardcoded curve support
dc->caps.color.dpp.post_csc = 1; // CSC matrix
dc->caps.color.dpp.gamma_corr = 1; // New  Gamma Correction  block for degamma user LUT;
dc->caps.color.dpp.dgam_rom_for_yuv = 0;
dc->caps.color.dpp.hw_3d_lut = 1; // 3D LUT support. If so, it's always preceded by a shaper curve. 
dc->caps.color.dpp.ogam_ram = 1; //  Blend Gamma  block for custom curve just after blending
// no OGAM ROM on DCN301
dc->caps.color.dpp.ogam_rom_caps.srgb = 0;
dc->caps.color.dpp.ogam_rom_caps.bt2020 = 0;
dc->caps.color.dpp.ogam_rom_caps.gamma2_2 = 0;
dc->caps.color.dpp.ogam_rom_caps.pq = 0;
dc->caps.color.dpp.ogam_rom_caps.hlg = 0;
dc->caps.color.dpp.ocsc = 0;
dc->caps.color.mpc.gamut_remap = 1; // Post-blending CTM (pre-blending CTM is always supported)
dc->caps.color.mpc.num_3dluts = pool->base.res_cap->num_mpc_3dlut; // Post-blending 3D LUT (preceded by shaper curve)
dc->caps.color.mpc.ogam_ram = 1; // Post-blending regamma.
// No pre-defined TF supported for regamma.
dc->caps.color.mpc.ogam_rom_caps.srgb = 0;
dc->caps.color.mpc.ogam_rom_caps.bt2020 = 0;
dc->caps.color.mpc.ogam_rom_caps.gamma2_2 = 0;
dc->caps.color.mpc.ogam_rom_caps.pq = 0;
dc->caps.color.mpc.ogam_rom_caps.hlg = 0;
dc->caps.color.mpc.ocsc = 1; // Output CSC matrix.

I included some inline comments in each element of the color caps to quickly describe them, but you can find the same information in the Linux kernel documentation. See more in struct dpp_color_caps, struct mpc_color_caps and struct rom_curve_caps. Now, using this guideline, we go through color capabilities of DPP and MPC blocks and talk more about mapping driver-specific properties to corresponding color blocks.

DPP Color Pipeline: Before Blending (Per Plane) Let s explore the capabilities of DPP blocks and what you can achieve with a color block. The very first thing to pay attention is the display architecture of the display hardware: previously AMD uses a display architecture called DCE

Display and Compositing Engine, but newer hardware follows DCN - Display Core Next.

The architectute is described by: `dc->caps.color.dpp.dcn_arch`

AMD Plane Degamma: TF and 1D LUT Described by: `dc->caps.color.dpp.dgam_ram`, `dc->caps.color.dpp.dgam_rom_caps`,`dc->caps.color.dpp.gamma_corr` AMD Plane Degamma data is mapped to the initial stage of the DPP pipeline. It is utilized to transition from scanout/encoded values to linear values for arithmetic operations. Plane Degamma supports both pre-defined transfer functions and 1D LUTs, depending on the hardware generation. DCN2 and older families handle both types of curve in the Degamma RAM block (`dc->caps.color.dpp.dgam_ram`); DCN3+ separate hardcoded curves and 1D LUT into two block: Degamma ROM (`dc->caps.color.dpp.dgam_rom_caps`) and Gamma correction block (`dc->caps.color.dpp.gamma_corr`), respectively. Pre-defined transfer functions:

they are hardcoded curves (read-only memory - ROM);

supported curves: sRGB EOTF, BT.709 inverse OETF, PQ EOTF and HLG OETF, Gamma 2.2, Gamma 2.4 and Gamma 2.6 EOTF.

The 1D LUT currently accepts 4096 entries of 8-bit. The data is interpreted as an array of `struct drm_color_lut` elements. Setting TF = Identity/Default and LUT as NULL means bypass. References:

[PATCH v3 04/32] drm/amd/display: add driver-specific property for plane degamma LUT

[PATCH v3 05/32] drm/amd/display: add plane degamma TF driver-specific property

[PATCH v3 19/32] drm/amd/display: add plane degamma TF and LUT support

AMD Plane 3x4 CTM (Color Transformation Matrix) AMD Plane CTM data goes to the DPP Gamut Remap block, supporting a 3x4 fixed point (s31.32) matrix for color space conversions. The data is interpreted as a `struct drm_color_ctm_3x4`. Setting NULL means bypass. References:

[PATCH v3 30/32] drm/amd/display: add plane CTM driver-specific property

[PATCH v3 31/32] drm/amd/display: add plane CTM support

[PATCH v3 32/32] drm/amd/display: Add 3x4 CTM support for plane CTM

AMD Plane Shaper: TF + 1D LUT Described by: `dc->caps.color.dpp.hw_3d_lut` The Shaper block fine-tunes color adjustments before applying the 3D LUT, optimizing the use of the limited entries in each dimension of the 3D LUT. On AMD hardware, a 3D LUT always means a preceding shaper 1D LUT used for delinearizing and/or normalizing the color space before applying a 3D LUT, so this entry on DPP color caps `dc->caps.color.dpp.hw_3d_lut` means support for both shaper 1D LUT and 3D LUT. Pre-defined transfer function enables delinearizing content with or without shaper LUT, where AMD color module calculates the resulted shaper curve. Shaper curves go from linear values to encoded values. If we are already in a non-linear space and/or don t need to normalize values, we can set a Identity TF for shaper that works similar to bypass and is also the default TF value. Pre-defined transfer functions:

there is no DPP Shaper ROM. Curves are calculated by AMD color modules. Check `calculate_curve()` function in the file `amd/display/modules/color/color_gamma.c`.

supported curves: Identity, sRGB inverse EOTF, BT.709 OETF, PQ inverse EOTF, HLG OETF, and Gamma 2.2, Gamma 2.4, Gamma 2.6 inverse EOTF.

The 1D LUT currently accepts 4096 entries of 8-bit. The data is interpreted as an array of `struct drm_color_lut` elements. When setting Plane Shaper TF (!= Identity) and LUT at the same time, the color module will combine the pre-defined TF and the custom LUT values into the LUT that s actually programmed. Setting TF = Identity/Default and LUT as NULL works as bypass. References:

[PATCH v3 10/32] drm/amd/display: add plane shaper LUT and TF

[PATCH v3 23/32] drm/amd/display: add plane shaper LUT support

[PATCH v3 24/32] drm/amd/display: add plane shaper TF support

AMD Plane 3D LUT Described by: dc->caps.color.dpp.hw_3d_lut The 3D LUT in the DPP block facilitates complex color transformations and adjustments. 3D LUT is a three-dimensional array where each element is an RGB triplet. As mentioned before, the dc->caps.color.dpp.hw_3d_lut describe if DPP 3D LUT is supported. The AMD driver-specific property advertise the size of a single dimension via LUT3D_SIZE property. Plane 3D LUT is a blog property where the data is interpreted as an array of struct drm_color_lut elements and the number of entries is LUT3D_SIZE cubic. The array contains samples from the approximated function. Values between samples are estimated by tetrahedral interpolation The array is accessed with three indices, one for each input dimension (color channel), blue being the outermost dimension, red the innermost. This distribution is better visualized when examining the code in [RFC PATCH 5/5] drm/amd/display: Fill 3D LUT from userspace by Alex Hung:

+	for (nib = 0; nib < 17; nib++)  
+		for (nig = 0; nig < 17; nig++)  
+			for (nir = 0; nir < 17; nir++)  
+				ind_lut = 3 * (nib + 17*nig + 289*nir);
+
+				rgb_area[ind].red = rgb_lib[ind_lut + 0];
+				rgb_area[ind].green = rgb_lib[ind_lut + 1];
+				rgb_area[ind].blue = rgb_lib[ind_lut + 2];
+				ind++;
+			 
+		 
+	 

In our driver-specific approach we opted to advertise it s behavior to the userspace instead of implicitly dealing with it in the kernel driver. AMD s hardware supports 3D LUTs with 17-size or 9-size (4913 and 729 entries respectively), and you can choose between 10-bit or 12-bit. In the current driver-specific work we focus on enabling only 17-size 12-bit 3D LUT, as in [PATCH v3 25/32] drm/amd/display: add plane 3D LUT support:

+		/* Stride and bit depth are not programmable by API yet.
+		 * Therefore, only supports 17x17x17 3D LUT (12-bit).
+		 */
+		lut->lut_3d.use_tetrahedral_9 = false;
+		lut->lut_3d.use_12bits = true;
+		lut->state.bits.initialized = 1;
+		__drm_3dlut_to_dc_3dlut(drm_lut, drm_lut3d_size, &lut->lut_3d,
+					lut->lut_3d.use_tetrahedral_9,
+					MAX_COLOR_3DLUT_BITDEPTH);

A refined control of 3D LUT parameters should go through a follow-up version or generic API. Setting 3D LUT to NULL means bypass. References:

AMD Plane Blend/Out Gamma: TF + 1D LUT Described by: `dc->caps.color.dpp.ogam_ram` The Blend/Out Gamma block applies the final touch-up before blending, allowing users to linearize content after 3D LUT and just before the blending. It supports both 1D LUT and pre-defined TF. We can see Shaper and Blend LUTs as 1D LUTs that are sandwich the 3D LUT. So, if we don t need 3D LUT transformations, we may want to only use Degamma block to linearize and skip Shaper, 3D LUT and Blend. Pre-defined transfer function:

there is no DPP Blend ROM. Curves are calculated by AMD color modules;

supported curves: Identity, sRGB EOTF, BT.709 inverse OETF, PQ EOTF, HLG inverse OETF, and Gamma 2.2, Gamma 2.4, Gamma 2.6 EOTF.

The 1D LUT currently accepts 4096 entries of 8-bit. The data is interpreted as an array of `struct drm_color_lut` elements. If `plane_blend_tf_property` != Identity TF, AMD color module will combine the user LUT values with pre-defined TF into the LUT parameters to be programmed. Setting TF = Identity/Default and LUT to NULL means bypass. References:

[PATCH v3 11/32] drm/amd/display: add plane blend

[PATCH v3 27/32] drm/amd/display: add plane blend LUT and TF support

MPC Color Pipeline: After Blending (Per CRTC)

DRM CRTC Degamma 1D LUT The degamma lookup table (LUT) for converting framebuffer pixel data before apply the color conversion matrix. The data is interpreted as an array of `struct drm_color_lut` elements. Setting NULL means bypass. Not really supported. The driver is currently reusing the DPP degamma LUT block (`dc->caps.color.dpp.dgam_ram` and `dc->caps.color.dpp.gamma_corr`) for supporting DRM CRTC Degamma LUT, as explaning by [PATCH v3 20/32] drm/amd/display: reject atomic commit if setting both plane and CRTC degamma.

DRM CRTC 3x3 CTM Described by: `dc->caps.color.mpc.gamut_remap` It sets the current transformation matrix (CTM) apply to pixel data after the lookup through the degamma LUT and before the lookup through the gamma LUT. The data is interpreted as a `struct drm_color_ctm`. Setting NULL means bypass.

DRM CRTC Gamma 1D LUT + AMD CRTC Gamma TF Described by: `dc->caps.color.mpc.ogam_ram` After all that, you might still want to convert the content to wire encoding. No worries, in addition to DRM CRTC 1D LUT, we ve got a AMD CRTC gamma transfer function (TF) to make it happen. Possible TF values are defined by `enum amdgpu_transfer_function`. Pre-defined transfer functions:

there is no MPC Gamma ROM. Curves are calculated by AMD color modules.

supported curves: Identity, sRGB inverse EOTF, BT.709 OETF, PQ inverse EOTF, HLG OETF, and Gamma 2.2, Gamma 2.4, Gamma 2.6 inverse EOTF.

The 1D LUT currently accepts 4096 entries of 8-bit. The data is interpreted as an array of `struct drm_color_lut` elements. When setting CRTC Gamma TF (!= Identity) and LUT at the same time, the color module will combine the pre-defined TF and the custom LUT values into the LUT that s actually programmed. Setting TF = Identity/Default and LUT to NULL means bypass. References:

[PATCH v3 12/32] drm/amd/display: add CRTC gamma TF driver-specific property

[PATCH v3 15/32] drm/amd/display: add CRTC gamma TF support

Others

AMD CRTC Shaper and 3D LUT We have previously worked on exposing CRTC shaper and CRTC 3D LUT, but they were removed from the AMD driver-specific color series because they lack userspace case. CRTC shaper and 3D LUT works similar to plane shaper and 3D LUT but after blending (MPC block). The difference here is that setting (not bypass) Shaper and Gamma blocks together are not expected, since both blocks are used to delinearize the input space. In summary, we either set Shaper + 3D LUT or Gamma.

Input and Output Color Space Conversion There are two other color capabilities of AMD display hardware that were integrated to DRM by previous works and worth a brief explanation here. The DC Input CSC sets pre-defined coefficients from the values of DRM plane `color_range` and `color_encoding` properties. It is used for color space conversion of the input content. On the other hand, we have de DC Output CSC (OCSC) sets pre-defined coefficients from DRM connector `colorspace` properties. It is uses for color space conversion of the composed image to the one supported by the sink. References:

[PATCH] amd/display/dc: Fix COLOR_ENCODING and COLOR_RANGE doing nothing for DCN20+

[PATCH v6 00/13] Enable Colorspace connector property in amdgpu

The search for rainbow treasures is not over yet If you want to understand a little more about this work, be sure to watch Joshua and I presented two talks at XDC 2023 about AMD/Steam Deck colors on Gamescope:

The rainbow treasure map: advanced color management on Linux with AMD/Steam Deck

Rainbow Frogs: HDR + Color Management in Gamescope/SteamOS

In the time between the first and second part of this blog post, Uma Shashank and Chaitanya Kumar Borah published the plane color pipeline for Intel and Harry Wentland implemented a generic API for DRM based on VKMS support. We discussed these two proposals and the next steps for Color on Linux during the Color Management workshop at XDC 2023 and I briefly shared workshop results in the 2023 XDC lightning talk session. The search for rainbow treasures is not over yet! We plan to meet again next year in the 2024 Display Hackfest in Coru a-Spain (Igalia s HQ) to keep up the pace and continue advancing today s display needs on Linux. Finally, a HUGE thank you to everyone who worked with me on exploring AMD s color capabilities and making them available in userspace.

A big thank you goes to my parents this week for contributing to my survival fund. With that I was able to make a big push on fixing some outstanding issues on some of our snaps.

Marble! Now shows all maps and finds its plugins properly.

Neochat: A significant fix regarding libsecret in which left users with endless loading screen because it could not authenticate. Bug https://bugs.kde.org/show_bug.cgi?id=473003 This actually affected any app in KDE that uses libsecret KDE desktops do not ship with gnome-keyring, so this is why sometimes installing it would fix the issue ( if the portals were installed and working correctly AND XDG variables were set correctly). In most cases it works out of the box. In some cases, you must install gnome-keychain via apt and reinstall neochat to setup a new account and it will then prompt to save to keyring. If you are a KDE desktop user and wish to use Kwallet you can sudo snap connect neochat:password-manager-service :password-manager-service , my next order of business is to set up kwallet as a service inside the snaps. Should funding allow.

Kdevelop: New release . MR to fix wayland no start issues. https://invent.kde.org/kdevelop/kdevelop/-/merge_requests/510
Kid3: Fixed qml scripts issue https://bugs.kde.org/show_bug.cgi?id=473556
Kate: New release. MR to fix wayland no start issues https://invent.kde.org/utilities/kate/-/merge_requests/1333
Krita! 5.2.1 coming as soon as MR https://invent.kde.org/graphics/krita/-/merge_requests/1987 is approved and merged. I have successfully built and installed locally, great stuff!
Store icons have been fixed.
Another pile of 23.08.2 releases almost at 100% now.

KDE neon: No major blowups this week. Worked out issues with kmail-account-wizard thanks to David R! This is now in the hands of upstream ( porting not complete ) Worked on more orange -> green packaging fixes. Debian: Fixed bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054713 in squashfuse Thanks for stopping by. Please help fund my efforts! <noscript><a href="https://liberapay.com/sgmoore/donate"><img alt="Donate using Liberapay" src="https://liberapay.com/assets/widgets/donate.svg" /></a></noscript> Donate https://gofund.me/b8b69e54

Already November. Been playing a bit with ureadahead. Build systems are hard. Resurrecting libnih to build again was a pain. Some tests rely on not being root so simply running things in Docker made it fail.

While Yang our cat tries to lure in unsuspecting birds on the bird feeder, I have been busy working on many things. First things first though, a big thank you to all that donated to my Internet bill. I was able to continue my work without interruption. KDE neon: A busy week in KDE neon as https://kde.org/announcements/plasma/5/5.27.9/ was released! We have it ready to update in User edition or if you would like to download the new ISO you can find it here: https://neon.kde.org/download I highly advise the User Edition as Unstable is volatile right now with Qt6 transition and ABI breakage. Which leads me to the next busy work for the week. Plasma 6 exploded breaking unstable desktops all over, including mine! A library changed and it was not backward compatible, so we had to rebuild the Qt6 $world to get Plasma and PIM functional again. I am happy to report it is all fixed now, but I cannot stress enough, if you don t want to chance broken things, please use the User Edition! I also continued the orange -> green build effort in making sure all our runtime dependencies are up to date. This fixes odd UI bugs and developers have all the build dependencies needed to build their applications. KDE Snaps: Several more 23.08.2 snaps have arrived in the snap store including the new to snaps Kamoso!

I have an auto-connect request to the snap-store policy folks, but until it is approved please snap connect kamoso:camera :camera I have a pile of new MR s in for non release service applications and some fixes for issues found while testing. While this new workflow does take a bit longer waiting for approvals I like it much better as I am developing closer relationships with the application developers. I have made significant progress on the Kf6 ( Qt6 based ) content snap. I am about 90% complete. While this doesn t mean much for users yet, it will when KDE applications release their qt6 ports starting the next major release cycle. I will be ready! The last bit for snap work is I have almost completed my akonadi service snap. This will connect to all KDE PIM snaps so they share data. Akonadi is the background database that ties all the PIM applications together. Debian: This week I have worked on updates for several golang packages including charmbracelet/lipgloss charmbracelet/bubbles, and muesli-termenv. unfortunately I am stuck golang-github-aymanbagabas-go-osc52. The work is done in salsa but the maintainer has not uploaded. I have shot an email to the maintainer. I have also begun mentoring my first potential future DD! I reviewed his python-scienceplots and python-art which should land in Debian soon. Thanks for stopping by! As usual, if you can please spare some change, consider a donation. All proceeds go to surviving another day to work on cool things to land on your desktop! https://gofund.me/b8b69e54 <noscript><a href="https://liberapay.com/sgmoore/donate"><img alt="Donate using Liberapay" src="https://liberapay.com/assets/widgets/donate.svg" /></a></noscript> Donate

Thunderbird in Debian stable (Bookworm) has received Thunderbird v115.3.1 as a security update. With it comes "Supernova", a UI redesign. There is a Mozilla blogpost with a walk-through of the new UI. Unfortunately it features a super eye-catching "New Message" button that - thankfully - can be disabled. Even the whole space above the email folder pane can be recovered by disabling the folder pane header at Burger Menu ( ) -> View -> Folders -> Folder Pane Header. Unfortunately there is no way to remove the same eye-catching "New Event" button for the Calendar view via a UI setting. Thunderbird New event button, German locale

This needs a user CSS file to override the button as non-visible. To make it process the user CSS Thunderbird needs a config setting to be enabled:

Burger Menu ( ) -> Settings -> General
Scroll down all the way
Click the Config editor... button on the bottom right
Accept that hell will freeze over because you configure software
Search for toolkit.legacyUserProfileCustomizations.stylesheets
Toggle the value to true to enable the user CSS

You can manually add user_pref("toolkit.legacyUserProfileCustomizations.stylesheets", true); to ~/.thunderbird/abcdefgh.default/prefs.js to the same effect (do this while Thunderbird is not running; replace abcdefgh with your Thunderbird profile ID). Now create a new directory ~/.thunderbird/abcdefgh.default/chrome/, again replacing abcdefgh with your profile ID. Inside the new directory create a userChrome.css file with the following content:

/* Hide Calendar New Event button */
#primaryButtonSidePanel
display: none !important;

Restart Thunderbird. And enjoy less visual obstruction when using the Calendar.

I have completed the the Big move ! There are still a few lingering MR s, but I am sure they will be approved so I can merge soon. With the move I was also able to release 23.08.2 for most release service applications. Enjoy! You can find them all here: https://snapcraft.io/search?q=KDE I still need to raise a bit more to pay the Internet bill. If you can spare some change please consider a donation. Thank you! <script src= https://liberapay.com/sgmoore/widgets/button.js ></script> <noscript><a href= https://liberapay.com/sgmoore/donate ><img alt= Donate using Liberapay src= https://liberapay.com/assets/widgets/donate.svg ></a></noscript> Donate https://gofund.me/b8b69e54

Review: Wolf Country, by Mar Delaney

Publisher:	Kalikoi
Copyright:	September 2021
ASIN:	B09H55TGXK
Format:	Kindle
Pages:	144

Wolf Country is a short lesbian shifter romance by Mar Delaney, a pen name for Layla Lawlor (who is also one of the writers behind the shared pen name Zoe Chant). Dasha Volkova is a werewolf, a member of a tribe of werewolves who keep to themselves deep in the wilds of Alaska. She's just become an adult and is wandering, curious and exploring, seeing what's in the world outside of her sheltered childhood. A wild chase after a hare, purely for the fun of it, is sufficiently distracting that she doesn't notice the snare before she steps in it going full speed. Laney Rosen is not a werewolf. She's a landscape painter who lives a quiet and self-contained life in an isolated cabin in the wilderness. She only stumbles across Dasha because she got lost on the snowmobile tracks taking photographs. Laney assumes Dasha is a dog caught in a poacher's trap, and is quite surprised when the pain of getting her out of the snare causes Dasha to shapeshift into a naked woman. This short book is precisely what it sounds like, which I appreciate in a romance novel. Woman meets wolf and discovers her secret accidentally, woman is of course entirely trustworthy although wolf can't know that, attraction at first sight, they have to pitch a tent in the wilderness and there's only one sleeping bag, etc. Nothing here is going to surprise you, but it's gentle and kind and fulfills the romance contract of a happy ending. It's not particularly steamy; the focus is on the relationship and the mutual attraction rather than on the sex. The best part of this book is probably the backdrop. Delaney lives in Alaska, and it shows in both the attention to the details of survival and heat and in the landscape descriptions (and the descriptions of Laney's landscapes). Dasha's love of Laney's paintings is one of the most heart-warming parts of the book. Laney has retinitis pigmentosa and is slowly losing her vision, which I thought was handled gracefully and well in the story. It creates real problems and limitations for her, but it also doesn't define her or become central to her character. Both Dasha and Laney are viewpoint characters and roughly alternate tight third-person viewpoint chapters. There are a few twists: potential parental disapproval on Dasha's part and some real physical danger from the person who set the trap, but most of the story is the two woman getting to know each other and getting past the early hesitancy to name what they're feeling. Laney feels a bit older than Dasha just because she's out on her own and Dasha was homeschooled and very sheltered, but both of them feel very young. This is Dasha's first serious relationship. Delaney does use the fated lover trope, which seems worth a warning in case you're not in the mood for that. Werewolves apparently know when they've found their fated mate and don't have a lot of choice in the matter. This is a common paranormal and fantasy romance trope that I find disturbing if I think about it too hard. Thankfully, here it's not much of a distraction. Dasha is such an impulsive, think-with-her-heart sort of character that the immediate conclusion that Laney is her fated mate felt in character even without the werewolf lore. I read this based on a random recommendation from Yoon Ha Lee when I was in the mood for something light and kind and uncomplicated, and I got exactly what I expected and was in the mood for. The writing isn't the best, but the landscape descriptions aren't bad and the characterization is reasonably good if you're in the mood for brightly curious but not particularly wise. Recommended if you're looking for this sort of thing. Rating: 7 out of 10

Review: A Killing Frost, by Seanan McGuire

Series:	October Daye #14
Publisher:	DAW
Copyright:	2020
ISBN:	0-7564-1253-6
Format:	Kindle
Pages:	351

A Killing Frost is the 14th book in the October Daye urban fantasy series and a direct plot sequel to the events of The Brightest Fell. You definitely cannot start here. This review has some relationship spoilers here for things that you would be expecting after the first five or six books, but which you wouldn't know when reading the first few books of the series. If you haven't started the series yet but plan to, consider skipping this review; if you haven't started reading this series, it will probably be meaningless anyway. Finally, events seem to have slowed, enough trauma has been healed, and Toby is able to seriously consider getting married. However, no sooner is the thought voiced than fae politics injects itself yet again. In order to get married without creating potentially substantial future problems for herself and her family, Toby will have to tie up some loose ends. Since one of those loose ends is a price from the Luidaeg that has been haunting her family for decades, this is easier said than done. The Brightest Fell had a very unsatisfying ending. This, after a two book interlude, is the proper end to that story. I picked this up when I had a bunch of stressful things going on and I wanted to be entertained without having to do much work as a reader. Once again, this series delivered exactly that. The writing is repetitive and a bit clunky, McGuire hammers the same emotional points into the ground, and one does wonder about Toby's tendency to emulate a half-human battering ram, but every book has me engrossed and turning the pages. Everyone should have at least one book series on the go that offers reliable, low-effort entertainment. The initial lever that McGuire uses to push Toby into this plot (fae marriage requirements that had never previously been mentioned) felt rather strained and arbitrary, and I spent the first part of the book grumbling a bit about it. However, there is a better reason for this complication that is revealed with time, and which implies some interesting things about how the fae see heroes and how they use them to solve problems. Now I'm wondering if McGuire will explore that some more in later books. This is the "all is revealed" book about Simon Torquill. As we get later into the series, these "all is revealed" books are coming more frequently. So far, I'm finding the revelations satisfying, which is a lot harder than it looks with a series this long and with this many hidden details. There are a few directions the series is taking that aren't my favorite (the Daoine Sidhe obsession with being the Best Fae is getting a bit boring, for example), but none of them seem egregiously off, and I'm deeply invested in the answers to the remaining questions. Toby hits a personal record here for not explaining the dangerous things she's doing because people might talk her out of it. It makes for a tense and gripping climax, but wow I felt for her friends and family, and substantial parts of that risk seemed unnecessary. This is pointed out to her in no uncertain terms, and I'm wondering if it will finally stick. Toby's tendency to solve complicated problems by bleeding on them is part of what gives this series its charm, but I wouldn't mind her giving other people more of a chance to come up with better plans. I did not like this one as well as the previous two books, mostly because I prefer the Luidaeg-centric stories to the Daoine-Sidhe-centric stories, but if you're enjoying the series to this point, this won't be an exception. It's a substantial improvement on The Brightest Fell and did a lot to salvage that story for me, although there are still some aspects of it that need better explanations. Followed by When Sorrows Come. As usual, there is a novella included in at least the Kindle edition. "Shine in Pearl": I was again hoping for more Gillian, but alas. Instead, and breaking with the tendency for the novellas to be side stories unrelated to the main novel, this fleshes out Simon's past and the other primary relationship driving the novel's plot. It's... fine? The best parts by far are the scenes from Dianda's viewpoint, which are just as refreshingly blunt as Dianda is elsewhere. Neither of the other two characters are favorites of mine, and since the point of the story is to describe the tragedy that is resolved in the plot of the main novel, it's somewhat depressing. Not my favorite of the novellas; not the worst of them. (6) Rating: 7 out of 10

It s that time of year already! We have hit our first freeze of the year. While the kitties keep warm by the wood burning stove, I have been busy with many updates and fixes in a variety of projects. KDE neon: It s true, Neon unstable has been very unstable. Due to a few factors including a builder being out of space, timed with a new Qt release. There is a cost with living in unstable land with bleeding edge releases. It takes time and finesse to get everything happy, especially with major transitions such as Qt. The drive issue was just bad timing. We worked night and day ( quite literally with people spanning from the US, Europe and Australia ) to get everything happy again. I know it s frustrating when things are broken, but please keep in mind, most of us are volunteers. I am happy to report, it is once again stable. If you continue to experience issues please report them on https://bugs.kde.org there have been a few cases where there were rogue apt sources lists creating issues. We also have the User edition which is much more stable!

KDE Snaps: The big move to snapcraft files per repo continues. With that comes a new version 23.08.2. This big win this week was Audiotube! I have finally got this snap working. With a combination of snappy-debug and snap run gdb audiotube I was able to find all the hidden dependencies such as yt-dlp needed to be built with ffmpeg support and it needed a newer ytmusicapi as the version it called for was broken with gettext translations. I also had to fix the dbus name as it was not the standard org.kde.app. The final fix was it required the alsa plug and layouts adjusted to point to the snap alsa libraries ( which fixed the very important sound feature ). Who says you can t teach an old dog new tricks. Unfortunately, it still requires devmode to run, as it has one last network issue even with all the network plugs. I have to set it aside for now, as I have many more snaps to migrate. However, if you want to enjoy youtube music with this super awesome app you can, just append devmode when installing. Enjoy! The following apps have now migrated to their respective KDE repos and have the snap recipes in launchpad for automated builds:

Blinken
Bovo
Calindori
Dragon
Dolphin ( still needs work )
Digikam ( still needs work )
Elisa ( Working on new qml issue )
Falkon
Filelight
GCompris
Granatier
Ghostwriter
Gwenview ( working on missing dependency )
Haruna ( still needs work )
isoimagewriter ( working on gpg support )
Itinerary
Juk
K3b ( still needs work )

A new content pack with the latest Frameworks 5.110 and Qt 5.15.11 is complete and the neon extension update will follow after the required global autoconnect is approved from the store. Debian: I have caught up on my dashboard with new releases, fixed test failures, and FTBFS on the more obscure arches. The following debian packages have been uploaded to unstable:

description
umbrello
squashfuse
golang-github-muesli-mango
golang-github-muesli-roff
speechpy-fast
lingua-franca

If you have made it this far, thank you! As you can see I am quite busy and there is still much to do. If you can possibly spare a donation so I can continue my efforts in KDE neon / KDE Snaps / and Debian, it would be so appreciated. I enjoy doing this work and I hope it benefits someone out there. Have a lovely day and thanks for stopping by. Donate https://gofund.me/b8b69e54

Like each month, have a look at the work funded by Freexian s Debian LTS offering.

Debian LTS contributors In September, 21 contributors have been paid to work on Debian LTS, their reports are available:

Abhijith PA did 10.0h (out of 0h assigned and 14.0h from previous period), thus carrying over 4.0h to the next month.

Adrian Bunk did 7.0h (out of 17.0h assigned), thus carrying over 10.0h to the next month.

Anton Gladky did 9.5h (out of 7.5h assigned and 7.5h from previous period), thus carrying over 5.5h to the next month.

Bastien Roucari s did 16.0h (out of 15.5h assigned and 1.5h from previous period), thus carrying over 1.0h to the next month.

Ben Hutchings did 17.0h (out of 17.0h assigned).

Chris Lamb did 17.0h (out of 17.0h assigned).

Emilio Pozuelo Monfort did 30.0h (out of 30.0h assigned).

Guilhem Moulin did 18.25h (out of 18.25h assigned).

Helmut Grohne did 10.0h (out of 10.0h assigned).

Lee Garrett did 17.0h (out of 16.5h assigned and 0.5h from previous period).

Markus Koschany did 40.0h (out of 40.0h assigned).

Ola Lundqvist did 4.5h (out of 0h assigned and 24.0h from previous period), thus carrying over 19.5h to the next month.

Roberto C. S nchez did 5.0h (out of 12.0h assigned), thus carrying over 7.0h to the next month.

Santiago Ruano Rinc n did 7.75h (out of 16.0h assigned), thus carrying over 8.25h to the next month.

Sean Whitton did 7.0h (out of 7.0h assigned).

Sylvain Beucler did 10.5h (out of 17.0h assigned), thus carrying over 6.5h to the next month.

Thorsten Alteholz did 14.0h (out of 14.0h assigned).

Tobias Frost did 13.25h (out of 16.0h assigned), thus carrying over 2.75h to the next month.

Evolution of the situation In September, we have released 44 DLAs. The month of September was a busy month for the LTS Team. A notable security issue fixed in September was the high-severity CVE-2023-4863, a heap buffer overflow that allowed remote attackers to perform an out-of-bounds memory write via a crafted WebP file. This CVE was covered by the three DLAs of different packages: firefox-esr, libwebp and thunderbird. The libwebp backported patch was sent to upstream, who adapted and applied it to the 0.6.1 branch. It is also worth noting that LTS contributor Markus Koschany included in his work updates to packages in Debian Bullseye and Bookworm, that are under the umbrella of the Security Team: xrdp, jetty9 and mosquitto. As every month, there was important behind-the-scenes work by the Front Desk staff, who triaged, analyzed and reviewed dozens of vulnerabilities, to decide if they warrant a security update. This is very important work, since we need to trade-off between the frequency of updates and the stability of the LTS release.

Thanks to our sponsors Sponsors that joined recently are in bold.

Platinum sponsors:

TOSHIBA (for 97 months)

Civil Infrastructure Platform (CIP) (for 65 months)

Gold sponsors:

Roche Diagnostics International AG (for 108 months)

Linode (for 102 months)

Babiel GmbH (for 91 months)

Plat Home (for 91 months)

University of Oxford (for 47 months)

Deveryware (for 34 months)

VyOS Inc (for 29 months)

EDF SA (for 18 months)

Silver sponsors:

Domeneshop AS (for 112 months)

Nantes M tropole (for 106 months)

Univention GmbH (for 98 months)

Universit Jean Monnet de St Etienne (for 98 months)

Ribbon Communications, Inc. (for 92 months)

Exonet B.V. (for 82 months)

Leibniz Rechenzentrum (for 76 months)

CINECA (for 65 months)

Minist re de l Europe et des Affaires trang res (for 59 months)

Cloudways Ltd (for 49 months)

Dinahosting SL (for 47 months)

Bauer Xcel Media Deutschland KG (for 41 months)

Platform.sh (for 41 months)

Moxa Inc. (for 35 months)

sipgate GmbH (for 32 months)

OVH US LLC (for 30 months)

Tilburg University (for 30 months)

GSI Helmholtzzentrum f r Schwerionenforschung GmbH (for 21 months)

Soliton Systems K.K. (for 19 months)

Bronze sponsors:

Evolix (for 113 months)

Seznam.cz, a.s. (for 113 months)

Linuxhotel GmbH (for 110 months)

Intevation GmbH (for 109 months)

Daevel SARL (for 108 months)

Bitfolk LTD (for 107 months)

Megaspace Internet Services GmbH (for 107 months)

Greenbone AG (for 106 months)

NUMLOG (for 106 months)

WinGo AG (for 106 months)

Ecole Centrale de Nantes - LHEEA (for 102 months)

Entr ouvert (for 97 months)

Adfinis AG (for 94 months)

GNI MEDIA (for 89 months)

Laboratoire LEGI - UMR 5519 / CNRS (for 89 months)

Tesorion (for 89 months)

Bearstech (for 80 months)

LiHAS (for 80 months)

Catalyst IT Ltd (for 75 months)

Supagro (for 70 months)

Demarcq SAS (for 69 months)

Universit Grenoble Alpes (for 55 months)

TouchWeb SAS (for 47 months)

SPiN AG (for 44 months)

CoreFiling (for 39 months)

Institut des sciences cognitives Marc Jeannerod (for 34 months)

Observatoire des Sciences de l Univers de Grenoble (for 31 months)

Tem Innovations GmbH (for 25 months)

WordFinder.pro (for 25 months)

CNRS DT INSU R sif (for 24 months)

Alter Way (for 17 months)

Institut Camille Jordan (for 6 months)

Sick with COVID-19 and flu. This time around we had two different things going around the household. Failure to isolate the second case in the household resulted in more cases.

Search Results: "dan"

12 December 2023

Evolution of the situation In November, we have released 35 DLAs.

7 December 2023

3 December 2023

30 November 2023

28 November 2023

Changes in version 0.1.11 (2023-11-28) RcppExports.cpp has been regenerated under an update Rcpp to address a print format warning (Dirk in #88).

26 November 2023

13 November 2023

11 November 2023

What is new in 1.0?

Release tags Releases can have tags now, just like components. This is generally not a feature that I expect to be used much, but in certain instances it can become useful with a cooperating software center, for example to tag certain releases as long-term supported versions.

Multi-platform support Thanks to the interest and work of many volunteers, AppStream (mostly) runs on FreeBSD now, a NetBSD port exists, support for macOS was written and a Windows port is on its way! Thank you to everyone working on this

10 November 2023

7 November 2023

CTM (Color Transformation Matrices): Color transformation matrices facilitate the transition between different color spaces, playing a crucial role in color space conversion.

HDR Multiplier: HDR multiplier is a factor applied to the color values of an image to increase their overall brightness.

MPC Color Pipeline: After Blending (Per CRTC)

DRM CRTC 3x3 CTM Described by: dc->caps.color.mpc.gamut_remap It sets the current transformation matrix (CTM) apply to pixel data after the lookup through the degamma LUT and before the lookup through the gamma LUT. The data is interpreted as a struct drm_color_ctm. Setting NULL means bypass.

Others

3 November 2023

1 November 2023

27 October 2023

22 October 2023

18 October 2023

15 October 2023

13 October 2023

12 October 2023

6 October 2023

Changes in version 0.1.11 (2023-11-28)

`RcppExports.cpp` has been regenerated under an update Rcpp to address a `print` format warning (Dirk in #88).

DRM CRTC 3x3 CTM Described by: `dc->caps.color.mpc.gamut_remap` It sets the current transformation matrix (CTM) apply to pixel data after the lookup through the degamma LUT and before the lookup through the gamma LUT. The data is interpreted as a `struct drm_color_ctm`. Setting NULL means bypass.